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ABSTRACT 

A unit test is a metliod for verifying tlie accuracy and the proper 
functioning of a portion of a program. Tliis work consists to study 
tlie relation and tlie approaches to test Object-Oriented Program- 
ming (OOP) programs and to propose a metamodel that enables the 
programmer to write the tests while writing the source code to be 
tested. 
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1. INTRODUCTION 

A unit test 1101 is a method for verifying the accuracy and the 
proper functioning of a portion of a program. This work consists 
to study the relation and the approaches to test OOP programs and 
to propose metamodel that enables the programmer to write the 
tests while writing the source code to be tested. By considering 
the current approaches used in the industry, the integration and the 
writing of the tests are hard tasks: most likely, the tools available 
require to write additional components manually and most of the 
time, the tests are not near of the source code to be tested. 

This paper is organized as follows. Section|2]gives a state of the 
art about the relation between OOP programs and the tests. Sec- 
tion |3] describes the proposed metamodel of unit testing for OOP 
languages. Section |4] gives an example of what could looks like 
an OOP environment which uses the proposed metamodel. finally, 
Section[5]contains the conclusion and future possible work. 

2. OOP AND UNIT TESTS 
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This section contains the motivations of testing OOP languages 
differently compared to testing procedural languages. Then, the 
levels of abtraction for the tests are defined. Finally, current ap- 
proaches to test OOP languages are discussed. 

2.1 Motivations of testing OOP languages dif- 
ferently compared to testing procedural lan- 
guages 

This section describes some reasons why an OOP language must 
be tested completely differently compared to procedural languages. 

Intuitively, specialization and aggregation combined to polymor- 
phism increases the difficulty to detect errors during the integration 
of several components. The primary goal consists of decreasing 
the maximum effort to test a unit by reusing as much as possible 
the tests |9, 5|. 

2.1.1 Test unit 

In procedural languages such as (C, Pascal, etc.), the principal 
units are the procedure and the module. However, the principal 
unit in an OOP language is the class jg]!!]!!). This difference has a 
huge impact on the methodology to test the software since several 
new OOP concepts are nonexistent in the procedural paradigm. 

2.1.2 Object and encapsulation 

Traditional techniques to test procedural languages are not nec- 
essary application to the object oriented paradigm since the encap- 
sulation reduces or eliminates the possibility to test a specific state 
of an attribute of an object | 9|. 

2.1.3 Specialization and inheritance 

A method is defines by one of the following characteristic {9): 

1. Inherited from the parent class without redefinition. 

2. Redefinition without any call to super. 

3. Redefinition with a call to super. 

4. A new method nonexistent in the parent classes. 

Existing works consider that the tests for cases 2, 3 and 4 must 
be retested completely compared to the first case which does not 
require any redefinition. 

2.1.4 Polymorphism 

Let ^(z) be a method named p which take a parameter z where z 
contains a method m. Depending on the dynamic type of z, several 
different methods m when z.m is called by polymorphism. It has 
a huge impact on the tests since several permutations of dynamic 
types must be passed for the parameters in order cover more lines 
of code. 



2. 7. 5 OOP language entity dimensions 
OOP language entities can be categorized as follows |T|: 

• Object: A class instance composed of several attributes and 
methods. An object represents a specific state. 

• Class: A model which factorizes the properties of its in- 
stances. 

• Class hierarchy: A class inherits the properties of its parent 
classes. 

• Package (or subsystem): A subsystem defines an interface 
presenting services. A subsystem regroups classes with strong 
semantic relations. Jin et al. has developed a mechanism 
which uses a metamodel which allows to test the coupling 
between units |8|. 

• System: Composed of a set of subsystems and links them 
together. 

2.2 Levels of abstraction for the tests 

The principal levels of abstraction for the test are the white box, 
the black box and the grey box ||4J: 

• White box: White box tests consider the implementation of 
the classes and the methods. 

• Black box: Black box tests does not take into account the 
implementation but only the interface units. 

• Grey box: Grey box tests take into account the white box and 
the black box levels. 
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Figure 1: System of N classes uing JUnit. 
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2.3 Current approaches to test OOP languages 

The approaches used in practice and in the research community 
are based on specifications or on programs. 

2.3.1 Specification-based 

The first approach to test an object-oriented program consists to 
use a certain specification language which describes what the pack- 
ages and the classes are actually doing. With this specification, it 
is possible to generate several tests automatically in order to verify 
the correctness of the implementation. 

Barbey et al. 1 2 1 have used an object oriented specification called 
Concurrent Object-Oriented Petri Nets (CO-OPN/2). In such a lan- 
guage, an interface describing the attributes in the methods is de- 
fined. The axioms enable the programmer to define the comporte- 
ments of the methods. The main problem in this work is that it does 
not take into account the characteristics of the OOP paradigm such 
as polymorphism, specialization, etc. 

Several researchers |6, 12 1 have defined that the state of an ob- 
ject is the result of a certain number of method calls. Doong et al. 
1 6 1 have used a similar approach compared to the work of Barbey 
and al., however they specified algebraically the behavior of the 
classes. The verification of the correctness of a method is done by 
generating a sequence of method calls. Then axioms are used to 
validate the results. 

The main problems with the specification-based approach is that 
the programmer must manipulate an extra language only in order 
to test the software. Also, the tests are most likely not near the 
source code to be tested which is not good by considerating that, in 
practice, the tests are not updated when the software change. 



Figure 2: Loss of the semantic relations with a typical system 
using JUnit. 

2.3.2 Program-based 

The program-based approach consists to get a certain confidence 
level by writing manually the tests in order to simulate the main 
possibilities of execution of the software. 

A standard in the industry is the JUnit Framework |3| well used 
for the Java programming language. The main components of the 
JUnit Framework are the tests suites and the tests cases. A test case 
regroups several tests of a class and the suite is used to contains 
several tests cases. Let say a system has A'^ classes. Then if there is 
one test case for each class, then the system will consists of 2*Ai'+l 
classes (Fig.lTJ. 

Another problem with JUnit is the loss of the semantic relations 
between test classes (Fig. |2j. In fact, classes TestClassl and Test- 
ClassS could be defined to be the subclass of TestClass 1 and reuse 
the code from TestClassl. However it would be done manually. We 
need something more automatic in order to reuse the tests. 

3. METAMODEL OF UNIT TESTING FOR 
OOP 

The proposed metamodel (Fig. O is an extension of the meta- 
model defined by Ducournau et al. |7|. The main motivation of 
this extension is to add properties specifically for unit tests in order 
to write unit tests by taking advantage of the mechanisms and the 
forces of OOP. 



CloOal Test Class 



f^a5 specializes 



contains name : String 



Global Property 



name : String 
tvpe : Type 



Local Test Class 



name ■ String q , 



1.- \ 1 

\ defines 



Local Praperty 



name : Siring 
type . Tvpe 



0.." 



redefines . 

I Local Test Propeny belongs to GloOal Test Fropeny 

name : String name String 



Figure 3: Metamodel of Unit Testing for OOP. 



A test property (Test Package, Local Test Class or Local Test 
Property) represents, in a complete OOP environment using the 
proposed metalmodel, a block of unit test code associated to a unit 
(A Package, a class or a property). 

The idea of incorporating test properties inside a class in the 
metamodel was inspired by the D Programming Language 111]. 
However, they do not considered OOP mechanisms such as inheri- 
tance and they have not modeled several layers of granularity. 

Here is a brief list of the main features of the proposed meta- 
model: 

• Covered dimensions: The proposed model enables to test 
packages (and sub-packages), classes and class properties. 

• Level of abstraction to define tests: Grey box. Testing pack- 
ages allows to link classes together regardless of the imple- 
mentation, which corresponds to the black box level. How- 
ever, testing classes and methods corresponds to the white 
box level since the tests and the implementation are regrouped 
within the same entity. 

• The program-based approach to test the software is used. 

• Test's units are the package, the class and the property class. 
On the other hand, the central unit is the class. 

• Encapsulation: the white box tests allow to access to all prop- 
erties compared to the black box tests which allow to access 
only to public properties. 

• Inheritance and specialization of tests are built by consider- 
ing the real world and the type safety. A super class' test is 
useful to test a subclass, so it is inherited by default. 

• The specialization is used for the tests class and for the tests 
property in order to reuse 

3.1 Class and properties 

As said, the proposed metamodel (Fig. O is an extension of the 
metalmodel proposed by Ducournau et al. |7 |. However, properties 
for tests are the following: 

• Properties to test classes. 

• Properties to test class properties. 

• Properties to test packages. 



The relations defined in (7) are also used and expressed as fol- 
lows: 

• Redefines (redef): Used to redefines a given entity. 

• Has (has): Used to know which knowledge is known by a 
certain entity. For example, it can be useful to know which 
tests are attached to a given local property. 

• Introduces (intra): Useful to know which entity has intro- 
duced a property or a test. 

• Belongs to (belongs): Useful to know which global entity is 
associated to a given local entity. 

• Defines (def): Used to know which entity has defined a cer- 
tain property. 

3.1.1 Property tests 

Global Test Property. 

Let's express the global test properties which belongs to a certain 
global property (gc) of a class c having super classes. Parents^ 
represents the set of all super classes of c: 



(1) 



Let Gc be the global properties of c, Lg^ the local properties of 
a given global property £ Gc of a class c and its super classes 
are defined by: 

Lga = U {ld\belongs{ld,gc),ld & Ld} (2) 

where belongs is a relation used to know if a local property be- 
longs to a global property. 

Then the global test properties (GTPg^ ) of a given global global 
property is given by: 

GTPg^= U {9tp\has{lc,gtp),gtpeGTPc} (3) 

where GPTc represents the global test properties of a class c. 
The relation has{lc, gtp) states that Ic knows gtp. 

A Global Test Property (GTP) is either inherited from a local 
property redefinition or introduced by a local property. The intro- 
duced global tests (IGTPg^ ) represent a sub set of GTPg^ : 

U {gtp\Mro{d,gtp), 
^iaeLg^has{lc,gtp), 

gtp e GTPc} C GTPg^ (4) 
where intro{d, gtp) means that d introduces gtp. 

Local Test Property. 

Let define all local test properties LTPc for a given class c, the 
local test properties of a given global property gtc is defined by: 

LTPCgt, = y {ltc\helongs(ltc,gtc)} (5) 
However, redefined tests must be removed: 



(J {ti|3t2e-LTPC,t,rede/(t2,ti)} 



tiGLTPCg 



(6) 



where redef{t2,ti) is a relation which expresses that the test t2 
redefines the test ti. 

3.1.2 Class tests 

Global Test Class. 

A global test class is either inherited from a super class or in- 
troduced by a given class. Let GTC be the global tests class of a 
system, GTCc the global tests class of a class c are defined by: 

GTCc^ [J {t|3cgParents,U{c}intro(c,t)} (7) 



Local Test Class. 

Let LTC be the local tests of a class. The local tests of a class c 
is given by: 

LTCCc= U {lt\3gtceGTcMlongs{lt,gtc)} (8) 

IteLTC 

However, redefinitions must be removed: 

LTCc = LTCCc ~ 

[Jti€LTCcA^^\^t2eLTCCaredef{t2,ti)} (9) 

3.2 Type-Safety 

In static typing languages, the redefinition of the return type must 
covariant and the redefinition of the parameters must be contravari- 
ant in order to have safe types. It does not poses any problem for 
the proposed metamodel since the metamodel is an extension of 
the existing properties and the notion of property and class is not 
altered. 

3.3 Property Conflicts 

3.3. 1 Global Test Property 

Name conflict of tests with inheritance: by using two 
times the same global test property associated to the 
same local property of a super class. 

The example in Fig. |4] is an example of a name conflict of 
tests by using two times the same global test property associated 
to the same local property of a super class. In this example, two 
tests for the same method operation are defined (Test 1 Operation 
and TestlOperation). Both classes B and C define a new test 
TestlOperation which causes a name conflict since two global test 
property with the same exists for the method operation. 

Solutions: 

1. Factorize B.TestlOperation and C.Test20peration in the su- 
per class A if the test in class B is the same than the one 
defined in class C. 

2. Redefine operation in B and C. 
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TestlOperationO : VDid 
operatiorO : void 
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TGSt20pGratiorO : void 


TestZOperationO : void 



Figure 4: Example of name conflict of tests with inheritance: 
by using two times the same global test property associated to 
the same local property of a super class. 



addO : void 



addO : void 
TestlAiidO : void 



addO : void 
TestlAddO : void 



Figure 5: Example of name conflict of global property test with 
multiple inheritance. 



Move TestlOperation in class A and redefine the local test 
property associated to TestlOperation in class B and C. 



Multiple Inheritance. 

The second type of possible conflict with global test properties 
is with multiple inheritance. The example with multiple inheri- 
tance (Fig. O does not cause any conflict for the tests since each 
new global test property is associated to the redefined add method. 
However, the method add is redefined in classes B and C and there 
exist three solutions for this problem. The tests must follow one of 
these three methods of conflict resolution: 

1 . Rename method add in B and C (for example B.addB, C.addC). 

2. Selection. In class D, the method add is redefined and a 
method between B.add and C.add is called and the associ- 
ated tests of that selection are now associated also to D.add. 

3. Unification. In class D, all tests from B and C are associated 
to D.add. 

3.3.2 Local Test Property 

Local Test Property name conflict with inheritance. 

Let A be a super class of B and C which introduces a method 
add and a test associated (Fig. The subclasses B and C re- 
define the local test property TestlAdd. Without class D, there 



addO : void 
TestlAddO : void 



Y 



redef TestlAddO : void 



redef TestlAddO : void 















D 









Figure 6: Example of Local Test Property name conflict with 
inheritance. 



exists no conflict. However, with a class D which can inherit 
both B.TestlAdd and C.TestlAdd there is a name conflict: which 
test should be chosen by the compiler ? Depending on the test, 
three strategies exists with multiple inheritance: rename, select and 
unify. 

3.4 Tests execution 

A compiler of an object oriented programming language can 
then execute automatically by using the meta information from the 
metamodel proposed (Algorithm[T](. 

Algorithm 1: Executing the tests by using the metamodel (Ex- 
ecTests). 



1 
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Data: P, a set of all packages, 
foreach p G P do 

// Test all packages 

foreach Test Package tp such that has{p, tp) do 

I Execute tp 
end 

foreach Class c such that has{p, c) do 
// Test all classes 
foreach Itc G LTCc do 
I Execute Itc 
end 

// Test all properties: 

foreach Global Property gp such that has{c, gp) do 
foreach Global Test Property such thatgtp 



foreach Local Test Property such that Itp 
G LTPgtp do 
I Execute Up 
end 



end 



end 



end 



end 



4. EXAMPLE 

This section contains a very basic example showing the strengths 
of the proposed metamodel in a real OOP environment like Java. 



color5 List<Color> 



"7^ 



TestNotNullO . void 
laslFoodEatenO : Food 



TeslGrassColorO : void 
laslFoodEatenO : Grass 



Figure 7: A very simple example: Cow, grass and mouse. 
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Figure 8: Metamodel of the example for the classes Animal, 
Mouse and Cow. 



4.1 First example: Cow, grass and mouse 

The example (Fig. |7]l contains a super class Animal and two 
subclasses Cow and Mouse. The Animal class defines a method 
lastFoodEaten which returns the last food that the animal has re- 
cently eaten. That class also introduces a new test property TestNotNull 
associated to the method lastFoodEaten. This test verify that the 
food exists when the animal has recently eaten something. The 
class Cow redefines the method lastFoodEaten and adds a new test 
TestGrassColor in order to verify that the grass has the right 
color (Green). 

The following listing presents the pseudocode of the first exam- 
ple: 



public class Food 
{ 

private List<Color> colors 
new ArrayList <Color >() ; 

public Food(Color c) 
{ 

colors . add ( c ) ; 

} 

public Food() 



// Returns true if the food is c. 
public boolean isColor ( Color c) 
{ /* ... */ } 



public class Grass extends Food 
{ 

public Grass ( ) 
{ 

colors . add ( Color . Green ) ; 

} 

} 

public class Animal 
{ 

private Food lastFoodEaten = null ; 

Test TestNotNull 
{ 

Current . lastFoodEaten = new Food(Color 

Food last = Current . lastFoodEaten () ; 
a s s er tTrue ( 1 a s t != null); 



Red) 



String output = 

this . getClass ( ) . getName + " . TestNotNilll 
System, out . println (output ); 

} 

public Food lastFoodEaten () 
{ 

String output = 

this . getClass (). getName + 

" . lastFoodEaten O^vl" 
System, out . println (output ); 

return lastFoodEaten ; 



public class Mouse extends Animal 

{ 

} 

public class Cow extends Animal 
{ 

Test TestGrassColor 
{ 

// Ok, it is grass . 

Current . lastFoodEaten = new Grass(); 

Food f = Current . lastFoodEaten ; 
asserlTrue (f. isColor(Color . Green )) ; 
System, out . println ( 

this . getClass (). getName + 

" . TestGrassColor" ); 

} 

public Grass lastFoodEaten () 
{ 

System, out . println ( 

this . getClass (). getName + 
" . lastFoodEaten ()^v2" ); 

if (lastFoodEaten instanceof Grass) 
return ( Grass ) lastFoodEaten ; 



return nul 



} 



Listing 1: Pseudocode of the example. 

The listing[T]contains a new keyword Current which correspond 
to a new instance of the current class, allocated only during the test. 
The following syntax: 

Test TestName { ... ) 



1}1 1 

defines a Property Test named TestName associated to the method 
/. Let say that a compiler tests those classes in the order of the dec- 
laration. Then, the following output would be printed: 

• Animal.lastFoodEatenO vl 

• Animal.TestNotNuU 

• Mouse.lastFoodEatenO vl 

• Mouse.TestNotNuU 

• Cow.lastFoodEatenO v2 

• Cow.TestNotNuU 

• Cow.lastFoodEatenO v2 
; • Cow. TestGrassColor 

We can clearly observe the benefit of using the proposed meta- 
model: the tests defined in a class are also used in the subclasses in 
order to cover more lines of code automatically. 

5. CONCLUSION AND FUTURE WORK 

There exist two approaches in order to test a OOP software: 
specification-based and program-based. The approach based on a 
specification enables the programmer to modelize the behavior of 
the objects, but this technique is not so interesting since it uses an 
extra language and the mechanisms used does not take into account 
the advantages of an OOP language. 

The proposed metamodel offers a new approach combining the 
advantages of the current approaches. The metamodel makes it 
possible to write unit tests inside the classes to be tested. It facil- 
itates the programmer to write and maintain a software unit. The 
proposed metamodel contains test properties for the class proper- 
ties, for the classes and for the packages. There exists specializa- 
tion links between the tests properties. The metamodel enables the 
compiler to execute automatically the tests. 

The future work is to embed the proposed metamodel in a real 
OOP environment in order to validate the usability and the reli- 
ability. Then, existing systems using for example JUnit will be 
converted to a system using the proposed metamodel in order to 
compare the testing approaches. 
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